La propiedad y los préstamos de Rust hacen cumplir la seguridad de la memoria

La propiedad y los préstamos de Rust pueden ser confusos si no comprendemos lo que realmente está sucediendo. Esto es particularmente cierto cuando se aplica un estilo de programación previamente aprendido a un nuevo paradigma; llamamos a esto un cambio de paradigma. La propiedad es una idea novedosa, pero difícil de entender al principio, pero se vuelve más fácil cuanto más trabajamos en ella. Antes de continuar con la propiedad y el préstamo de Rust, primero comprendamos qué son la "seguridad de la memoria" y la "fuga de memoria" y cómo los lenguajes de programación los tratan. ¿Qué es la seguridad de la memoria? La seguridad de la memoria se refiere al estado de una aplicación de software donde los punteros de memoria o las referencias siempre se refieren a la memoria válida. Debido a que la corrupción de la memoria es una posibilidad, hay muy pocas garantías sobre el comportamiento de un programa si no es seguro para la memoria. En pocas palabras, si un programa no es realmente seguro para la memoria, hay pocas garantías sobre su funcionalidad. Cuando se trata de un programa que no es seguro para la memoria, una parte malintencionada puede usar la falla para leer secretos o ejecutar código arbitrario en la máquina de otra persona. Usemos un pseudocódigo para ver qué memoria válida es. // pseudocode #1 - shows valid reference { // scope starts here int x = 5 int y = &x } // scope ends here En el pseudocódigo anterior, hemos creado una variable asignada con un valor de . Usamos el operador o la palabra clave para crear una referencia. Por lo tanto, la sintaxis de nos permite crear una referencia que se refiere al valor de . En pocas palabras, hemos creado una variable que posee y una variable que es una referencia a . x 10 & &x x x 5 y x Dado que ambas variables e están en el mismo bloque o ámbito, la variable tiene una referencia válida que se refiere al valor de . Como resultado, la variable tiene un valor de . x y y x y 5 Eche un vistazo al siguiente pseudocódigo. Como podemos ver, el alcance de está limitado al bloque en el que se crea. Nos metemos en referencias colgantes cuando intentamos acceder a fuera de su alcance. ¿Referencia pendiente…? ¿Qué es exactamente? x x // pseudocode #2 - shows invalid reference aka dangling reference { // scope starts here int x = 5 } // scope ends here int y = &x // can't access x from here; creates dangling reference Referencia colgante Una referencia colgante es un puntero que apunta a una ubicación de memoria que se le ha dado a otra persona o se ha liberado (liberado). Si un programa (también conocido como ) se refiere a la memoria que se ha liberado o borrado, podría fallar o causar resultados no deterministas. proceso Habiendo dicho eso, la inseguridad de es una propiedad de algunos lenguajes de programación que permite a los programadores manejar datos no válidos. Como resultado, la falta de seguridad de la memoria introdujo una variedad de problemas que podrían causar las siguientes vulnerabilidades de seguridad importantes: la memoria Lecturas fuera de los límites Escrituras fuera de los límites Use-After-Free Las vulnerabilidades causadas por la falta de seguridad de la memoria son la raíz de muchas otras amenazas de seguridad graves. Desafortunadamente, descubrir estas vulnerabilidades puede ser un gran desafío para los desarrolladores. ¿Qué es una pérdida de memoria? Es importante comprender qué es una fuga de memoria y cuáles son sus consecuencias. Una es una forma involuntaria de consumo de memoria en la que el desarrollador no puede liberar un bloque asignado de memoria en cuando ya no se necesita. Es simplemente lo opuesto a la seguridad de la memoria. Más sobre los diferentes tipos de memoria más adelante, pero por ahora, solo sepa que una almacena variables de longitud fija conocidas en el momento de la compilación, mientras que el tamaño de las variables que pueden cambiar más tarde en el tiempo de ejecución debe colocarse en el . fuga de memoria montón pila montón En comparación con la asignación de memoria de montón, la asignación de memoria de pila se considera más segura, ya que la memoria se libera automáticamente cuando ya no es relevante o necesaria, ya sea por el programador o por el propio tiempo de ejecución del programa. Sin embargo, cuando los programadores generan memoria en el montón y no la eliminan en ausencia de un recolector de basura (en el caso de C y C++), se desarrolla una fuga de memoria. Además, si perdemos todas las referencias a un fragmento de memoria sin desasignar esa memoria, entonces tenemos una fuga de memoria. Nuestro programa seguirá siendo dueño de esa memoria, pero no tiene forma de volver a usarla. Una pequeña fuga de memoria no es un problema, pero si un programa asigna una mayor cantidad de memoria y nunca la desasigna, la huella de memoria del programa seguirá aumentando, lo que provocará una denegación de servicio. Cuando un programa sale, el sistema operativo recupera inmediatamente toda la memoria que posee. Como resultado, una fuga de memoria solo afecta a un programa mientras se está ejecutando; no tiene efecto una vez que el programa ha terminado. Repasemos las consecuencias clave de las fugas de memoria. Las fugas de memoria reducen el rendimiento de la computadora al reducir la cantidad de memoria disponible (memoria en montón). Eventualmente hace que la totalidad o una parte del sistema deje de funcionar correctamente o se ralentice severamente. Los bloqueos suelen estar relacionados con pérdidas de memoria. Nuestro enfoque para descubrir cómo prevenir las fugas de memoria variará según el lenguaje de programación que estemos usando. Las fugas de memoria pueden comenzar como un problema pequeño y casi "imperceptible", pero pueden escalar muy rápidamente y abrumar los sistemas a los que afectan. Siempre que sea factible, debemos estar atentos a ellos y tomar medidas para rectificarlos en lugar de dejar que crezcan. Inseguridad de la memoria frente a fugas de memoria Las fugas de memoria y la inseguridad de la memoria son los dos tipos de problemas que han recibido la mayor atención en términos de prevención y reparación. Es importante tener en cuenta que arreglar uno no arregla automáticamente el otro. Varios tipos de memorias y cómo funcionan Antes de continuar, es importante comprender los diferentes tipos de memoria que usará nuestro código en tiempo de ejecución. Hay dos tipos de memoria, como sigue, y estas memorias están estructuradas de manera diferente. Registro del procesador Estático Pila Montón Tanto el como los tipos de memoria están fuera del alcance de esta publicación. registro del procesador estática Memoria de pila y cómo funciona La pila almacena datos en el orden en que se reciben y los elimina en el orden inverso. Se puede acceder a los elementos desde la pila en el orden de (LIFO). Agregar datos a la pila se denomina "empujar" y eliminar datos de la pila se denomina "hacer estallar". último en entrar, primero en salir Todos los datos almacenados en la pila deben tener un tamaño fijo conocido. En su lugar, los datos con un tamaño desconocido en el momento de la compilación o un tamaño que podría cambiar más adelante deben almacenarse en el montón. Como desarrolladores, no tenemos que preocuparnos por la y de memoria de pila; el compilador "realiza automáticamente" la asignación y desasignación de memoria de pila. Implica que cuando los datos en la pila ya no son relevantes (fuera del alcance), se eliminan automáticamente sin necesidad de nuestra intervención. asignación desasignación Este tipo de asignación de memoria también se conoce como , porque tan pronto como la función finaliza su ejecución, todos los datos que pertenecen a esa función se eliminan de la pila "automáticamente". asignación de memoria temporal Todos los tipos primitivos en Rust viven en la pila. Tipos como números, caracteres, segmentos, booleanos, matrices de tamaño fijo, tuplas que contienen primitivas y punteros de función pueden sentarse en la pila. Memoria de montón y cómo funciona A diferencia de una pila, cuando colocamos datos en el montón, solicitamos una cierta cantidad de espacio. El asignador de memoria localiza un lugar desocupado lo suficientemente grande en el montón, lo marca como en uso y devuelve una referencia a la dirección de esa ubicación. Esto se conoce como . asignación Asignar en el montón es más lento que empujar a la pila porque el asignador nunca tiene que buscar una ubicación vacía para colocar nuevos datos. Además, debido a que debemos seguir un puntero para llegar a los datos del montón, es más lento que acceder a los datos de la pila. A diferencia de la pila, que se asigna y desasigna en el momento de la compilación, la memoria de almacenamiento dinámico se asigna y desasigna durante la ejecución de las instrucciones de un programa. En algunos lenguajes de programación, para asignar memoria de montón, usamos la palabra clave . Esta palabra clave (también conocida como ) denota una solicitud de asignación de memoria en el montón. Si hay suficiente memoria disponible en el montón, el operador inicializa la memoria y devuelve la dirección única de esa memoria recién asignada. new new operador new Vale la pena mencionar que el programador o el tiempo de ejecución desasigna "explícitamente" la memoria del montón. ¿Cómo varios otros lenguajes de programación garantizan la seguridad de la memoria? Cuando se trata de la gestión de la memoria, particularmente la memoria en montón, preferimos que nuestros lenguajes de programación tengan las siguientes características: Preferimos liberar la memoria lo antes posible cuando ya no se necesite, sin sobrecarga de tiempo de ejecución. Nunca debemos mantener una referencia a un dato que ha sido liberado (también conocido como una referencia pendiente). De lo contrario, podrían producirse bloqueos y problemas de seguridad. La seguridad de la memoria se garantiza de diferentes maneras mediante lenguajes de programación mediante: (adoptada por C, C++) Desasignación de memoria explícita (adoptada por Java, Python y C#) Desasignación automática o implícita de memoria Gestión de memoria basada en regiones Sistemas de tipos lineales o únicos Tanto como los están más allá del alcance de esta publicación. la administración de memoria basada en regiones sistemas de tipo lineal Desasignación de memoria manual o explícita Los programadores deben liberar o borrar "manualmente" la memoria asignada cuando usan la administración de memoria explícita. Un operador de "desasignación" (por ejemplo, en C) existe en lenguajes con desasignación de memoria explícita. delete La recolección de basura es demasiado costosa en lenguajes de sistemas como C y C ++, por lo tanto, la asignación de memoria explícita continúa existiendo. Dejar la responsabilidad de liberar memoria al programador tiene el beneficio de darle al programador un control total sobre el ciclo de vida de la variable. Sin embargo, si los operadores de desasignación se usan incorrectamente, puede ocurrir una falla de software durante la ejecución. De hecho, este proceso manual de asignación y liberación es propenso a errores. Algunos errores de codificación comunes incluyen: Referencia colgante Pérdida de memoria A pesar de esto, preferimos la gestión manual de la memoria a la recolección de elementos no utilizados, ya que nos da más control y proporciona un mejor rendimiento. Tenga en cuenta que el objetivo de cualquier lenguaje de programación de sistemas es llegar lo más "cerca del metal" como sea posible. En otras palabras, favorecen un mejor rendimiento sobre las características de conveniencia en la compensación. Es enteramente nuestra responsabilidad (desarrolladores) asegurarnos de que nunca se utilice ningún puntero al valor que liberamos. En el pasado reciente, ha habido varios patrones comprobados para evitar estos errores, pero todo se reduce a mantener una disciplina de código rigurosa, lo que requiere aplicar el método de administración de memoria correcto de manera consistente. Los puntos clave son: Tener un mayor control sobre la gestión de la memoria. Menos seguridad como resultado de referencias colgantes y pérdidas de memoria. Resultados en un tiempo de desarrollo más largo. Desasignación de memoria automática o implícita La gestión automática de la memoria se ha convertido en una característica esencial de todos los lenguajes de programación modernos, incluido Java. En el caso de la desasignación automática de memoria, los sirven como administradores de memoria automáticos. Estos recolectores de basura revisan periódicamente el montón y reciclan fragmentos de memoria que no se utilizan. Gestionan la asignación y liberación de memoria en nuestro nombre. Así que no tenemos que escribir código para realizar tareas de administración de memoria. Eso es genial ya que los recolectores de basura nos liberan de la responsabilidad de administrar la memoria. Otra ventaja es que reduce el tiempo de desarrollo. recolectores de basura La recolección de basura, por otro lado, tiene una serie de inconvenientes. Durante la recolección de basura, el programa debe hacer una pausa y dedicar tiempo a determinar qué necesita limpiar antes de continuar. Además, la gestión automática de la memoria tiene mayores necesidades de memoria. Esto se debe al hecho de que un recolector de elementos no utilizados realiza la desasignación de memoria por nosotros, lo que consume tanto memoria como ciclos de CPU. Como resultado, la gestión automatizada de la memoria puede degradar el rendimiento de las aplicaciones, especialmente en aplicaciones grandes con recursos limitados. Los puntos clave son: Elimina la necesidad de que los desarrolladores liberen la memoria manualmente. Proporciona seguridad de memoria eficiente sin referencias colgantes ni fugas de memoria. Código más simple y directo. Ciclo de desarrollo más rápido. Tener menos control sobre la gestión de la memoria. Provoca latencia ya que consume memoria y ciclos de CPU. ¿Cómo garantiza Rust la seguridad de la memoria? Algunos lenguajes proporcionan , que busca memoria que ya no está en uso mientras se ejecuta el programa; otros requieren que el programador . Ambos modelos tienen ventajas y desventajas. La recolección de basura, aunque quizás sea la más utilizada, tiene algunos inconvenientes; facilita la vida de los desarrolladores a expensas de los recursos y el rendimiento. recolección de basura asigne y libere memoria explícitamente Habiendo dicho eso, uno brinda un de administración de memoria eficiente, mientras que el otro brinda mayor al eliminar las referencias colgantes y las fugas de memoria. Rust combina los beneficios de ambos mundos. control seguridad Rust adopta un enfoque diferente al de los otros dos, basado en un con un conjunto de reglas que el compilador verifica para garantizar la seguridad de la memoria. El programa no compilará si se viola alguna de estas reglas. De hecho, la propiedad reemplaza la recolección de basura en tiempo de ejecución con verificaciones en tiempo de compilación para la seguridad de la memoria. modelo de propiedad Lleva algún tiempo acostumbrarse a la propiedad porque es un concepto nuevo para muchos programadores, como yo. Propiedad En este punto, tenemos una comprensión básica de cómo se almacenan los datos en la memoria. Veamos más de cerca la en Rust. La principal característica distintiva de Rust es la propiedad, que garantiza la seguridad de la memoria en tiempo de compilación. propiedad Para empezar, definamos “propiedad” en su sentido más literal. La propiedad es el estado de “poseer” y “controlar” la posesión legal de “algo”. Dicho esto, debemos identificar y . En Rust, cada valor tiene una variable llamada . En pocas palabras, una variable es un propietario, y el valor de una variable es lo que posee y controla el propietario. quién es el propietario qué posee y controla el propietario propietario Con un modelo de propiedad, la memoria se libera automáticamente una vez que la variable que la posee queda fuera del alcance. Cuando los valores quedan fuera del alcance o su duración finaliza por algún otro motivo, se llama a sus destructores. Un destructor, en particular un destructor automatizado, es una función que elimina los rastros de un valor del programa mediante la eliminación de referencias y libera memoria. Comprobador de préstamo Rust implementa la propiedad a través del , un . El verificador de préstamos es un componente del compilador de Rust que realiza un seguimiento de dónde se usan los datos a lo largo del programa y, al seguir las reglas de propiedad, puede determinar dónde se deben liberar los datos. Además, el comprobador de préstamo garantiza que nunca se pueda acceder a la memoria desasignada en tiempo de ejecución. Incluso elimina la posibilidad de carreras de datos causadas por mutaciones (modificaciones) concurrentes. verificador de préstamo analizador estático Reglas de propiedad Como se indicó anteriormente, el modelo de propiedad se basa en un conjunto de reglas conocidas como , y estas reglas son relativamente sencillas. El compilador de Rust (rustc) aplica estas reglas: reglas de propiedad En Rust, cada valor tiene una variable llamada propietario. Solo puede haber un propietario a la vez. Cuando el propietario queda fuera del alcance, el valor se eliminará. Los siguientes errores de memoria están protegidos por estas reglas de propiedad de verificación en tiempo de compilación: es donde una referencia apunta a una dirección de memoria que ya no contiene los datos a los que se refería el puntero; este puntero apunta a datos nulos o aleatorios. Referencias colgantes: aquí es donde se accede a la memoria una vez que se ha liberado, lo que puede bloquearse. Esta ubicación de memoria también puede ser utilizada por piratas informáticos para ejecutar código. Usar después de liberar: aquí es donde se libera la memoria asignada y luego se libera nuevamente. Esto podría causar que el programa se bloquee, lo que podría exponer información confidencial. Esto también permite que un pirata informático ejecute cualquier código que elija. Liberaciones dobles: aquí es donde el programa intenta acceder a la memoria a la que no tiene permitido acceder. Fallas de segmentación: aquí Desbordamiento de es donde el volumen de datos excede la capacidad de almacenamiento del búfer de memoria, lo que hace que el programa se bloquee. búfer: aquí Antes de entrar en los detalles de cada regla de propiedad, es importante comprender las distinciones entre , y . copiar mover clonar Copiar Un tipo con un tamaño fijo (particularmente los tipos primitivos) puede almacenarse en la y extraerse cuando finaliza su alcance, y puede copiarse rápida y fácilmente para crear una nueva variable independiente si otra parte del código requiere el mismo valor en un alcance diferente. Debido a que copiar la memoria de la pila es económico y rápido, se dice que los tipos primitivos con un tamaño fijo tienen semántica de . Crea económicamente una réplica perfecta (un duplicado). pila copia Vale la pena señalar que los tipos primitivos con tamaño fijo implementan el rasgo de copia para hacer copias. let x = "hello"; let y = x; println!("{}", x) // hello println!("{}", y) // hello (asignada en montón y ampliable) y (tamaño fijo y no se puede mutar). En Rust, hay dos tipos de cadenas: String &str Debido a que se almacena en la pila, es más fácil copiar su valor para producir otra copia para . Este no es el caso de un valor que se almacena en el montón. Así es como se ve el marco de la pila: x y La duplicación de datos aumenta el tiempo de ejecución del programa y el consumo de memoria. Por lo tanto, copiar no es una buena opción para grandes cantidades de datos. Muevete En la terminología de Rust, "mover" significa que la propiedad de la memoria se transfiere a otro propietario. Considere el caso de los tipos complejos que se almacenan en el montón. let s1 = String::from("hello"); let s2 = s1; Podríamos suponer que la segunda línea (es decir ) haría una copia del valor en y lo vincularía a . Pero este no es el caso. let s2 = s1; s1 s2 Eche un vistazo al siguiente para ver qué le sucede a debajo del capó. Una cadena se compone de tres partes, que se almacenan en la . Los contenidos reales (hola, en este caso) se almacenan en el . String pila montón : apunta a la memoria que contiene el contenido de la cadena. Puntero : es la cantidad de memoria, en bytes, que utiliza actualmente el contenido de . Longitud String : es la cantidad total de memoria, en bytes, que ha recibido del asignador. Capacidad String En otras palabras, los metadatos se mantienen en la pila mientras que los datos reales se mantienen en el montón. Cuando asignamos a , los metadatos de la se copian, lo que significa que copiamos el puntero, la longitud y la capacidad que están en la pila. No copiamos los datos en el montón al que hace referencia el puntero. La representación de datos en la memoria se parece a la siguiente: s1 s2 String Vale la pena señalar que la representación no parece a la siguiente, que es como se vería la memoria si Rust también copiara los datos del montón. Si Rust hiciera esto, la operación podría ser extremadamente lenta en términos de rendimiento en tiempo de ejecución si los datos del montón fueran grandes. se s2 = s1 Tenga en cuenta que cuando los tipos complejos ya no están dentro del alcance, Rust a la función de eliminación para desasignar explícitamente la memoria del montón. Sin embargo, ambos punteros de datos en la Figura 6 apuntan a la misma ubicación, que no es la forma en que funciona Rust. Entraremos en detalles en breve. drop Como se indicó anteriormente, cuando asignamos a , la variable recibe una copia de los metadatos de (puntero, longitud y capacidad). Pero, ¿qué sucede con una vez que se ha asignado a ? Rust ya no considera que sea válido. Sí, has leído bien. s1 s2 s2 s1 s1 s2 s1 Pensemos en esta asignación por un momento. Considere lo que sucede si Rust todavía considera que es válido después de esta asignación. Cuando y quedan fuera del alcance, ambos intentarán liberar la misma memoria. Uh-oh, eso no es bueno. Esto se conoce como un y es uno de los errores de seguridad de la memoria. La corrupción de la memoria puede ser el resultado de liberar la memoria dos veces, lo que representa un riesgo para la seguridad. let s2 = s1 s1 s2 s1 error doble libre Para garantizar la seguridad de la memoria, Rust consideró que no era válido después de la línea . Por lo tanto, cuando ya no está dentro del alcance, Rust no necesita publicar nada. Examine qué sucede si tratamos de usar después de que se haya creado . s1 let s2 = s1 s1 s1 s2 let s1 = String::from("hello"); let s2 = s1; println!("{}, world!", s1); // Won't compile. We'll get an error. Obtendremos un error como el siguiente porque Rust le impide usar la referencia invalidada: $ cargo run Compiling playground v0.0.1 (/playground) error[E0382]: borrow of moved value: `s1` --> src/main.rs:6:28 | 3 | let s1 = String::from("hello"); | -- move occurs because `s1` has type `String`, which does not implement the `Copy` trait 4 | let s2 = s1; | -- value moved here 5 | 6 | println!("{}, world!", s1); | ^^ value borrowed here after move | = note: this error originates in the macro `$crate::format_args_nl` (in Nightly builds, run with -Z macro-backtrace for more info) For more information about this error, try `rustc --explain E0382`. Como Rust "trasladó" la propiedad de la memoria de a después de la línea , consideró que no era válido. Aquí está la representación de la memoria después de que s1 haya sido invalidado: s1 s2 let s2 = s1 s1 Cuando solo sigue siendo válido, solo liberará la memoria cuando salga del alcance. Como resultado, en Rust se elimina la posibilidad de un . ¡Eso es maravilloso! s2 doble error gratuito clon queremos copiar profundamente los datos del montón de , no solo los datos de la pila, podemos usar un método llamado . Aquí hay un ejemplo de cómo usar el método de clonación: Si String clone let s1 = String::from("hello"); let s2 = s1.clone(); println!("s1 = {}, s2 = {}", s1, s2); Cuando se usa el método de clonación, los datos del montón se copian en s2. Esto funciona perfectamente y produce el siguiente comportamiento: El uso del método de clonación tiene serias consecuencias; no solo copia los datos, sino que tampoco sincroniza ningún cambio entre los dos. En general, los clones deben planificarse con cuidado y con plena conciencia de las consecuencias. A estas alturas, deberíamos poder distinguir entre copiar, mover y clonar. Veamos ahora cada regla de propiedad con más detalle. Regla de propiedad 1 Cada valor tiene una variable llamada su propietario. Implica que todos los valores son propiedad de las variables. En el siguiente ejemplo, la variable posee el puntero a nuestra cadena, y en la segunda línea, la variable posee un valor 1. s x let s = String::from("Rule 1"); let n = 1; Regla de propiedad 2 Solo puede haber un propietario de un valor en un momento dado. Uno puede tener muchas mascotas, pero cuando se trata del modelo de propiedad, solo hay un valor en un momento dado :-) Veamos el ejemplo usando , que son de tamaño fijo conocido en tiempo de compilación. primitivas let x = 10; let y = x; let z = x; Hemos tomado 10 y lo hemos asignado a ; en otras palabras, posee 10. Entonces tomamos y lo asignamos a y también lo asignamos a . Sabemos que solo puede haber un propietario en un momento dado, pero aquí no recibimos ningún error. Entonces, lo que sucede aquí es que el compilador está haciendo copias de cada vez que lo asignamos a una nueva variable. x x x y z x El marco de pila para esto sería el siguiente: , y . Este, sin embargo, no parece ser el caso como este: , , y . Como sabemos, es el único propietario de este valor 10, y ni ni pueden poseer este valor. x = 10 y = 10 z = 10 x = 10 y = x z = x x y z Debido a que copiar la memoria de la pila es barato y rápido, se dice que los tipos primitivos con un tamaño fijo tienen semántica de , mientras que los tipos complejos la propiedad, como se indicó anteriormente. Así, en este caso, el compilador hace las . copia mueven copias En este punto, el comportamiento de es similar a la de otros lenguajes de programación. Para ilustrar las reglas de propiedad, necesitamos un tipo de datos complejo. vinculación de variables Veamos los datos almacenados en el montón y veamos cómo Rust entiende cuándo limpiarlos; el tipo String es un excelente ejemplo para este caso de uso. Nos centraremos en el comportamiento relacionado con la propiedad de String; estos principios, sin embargo, también se aplican a otros tipos de datos complejos. El tipo complejo, como sabemos, administra datos en el montón y su contenido se desconoce en el momento de la compilación. Veamos el mismo ejemplo que hemos visto antes: let s1 = String::from("hello"); let s2 = s1; println!("{}, world!", s1); // Won't compile. We'll get an error. En el caso del tipo , el tamaño podría expandirse y almacenarse en el montón. Esto significa: String En tiempo de ejecución, la memoria debe solicitarse al asignador de memoria (llamémoslo primera parte). Cuando terminemos de usar nuestro , debemos devolver (liberar) esta memoria al asignador (llamémoslo segunda parte). String Nosotros (los desarrolladores) nos encargamos de la primera parte: cuando llamamos a , su implementación solicita la memoria que necesita. Esta parte es casi común en todos los lenguajes de programación. String::from Sin embargo, la segunda parte es diferente. En lenguajes con un recolector de basura (GC), el GC realiza un seguimiento y limpia la memoria que ya no está en uso, y no tenemos que preocuparnos por eso. En idiomas sin un recolector de basura, es nuestra responsabilidad identificar cuándo ya no se necesita memoria y pedir que se libere explícitamente. Siempre ha sido una tarea de programación desafiante hacer esto correctamente: Desperdiciaremos la memoria si olvidamos. Tendremos una variable inválida si lo hacemos demasiado pronto. Obtendremos un error si lo hacemos dos veces. Rust maneja la desasignación de memoria de una manera novedosa para hacernos la vida más fácil: la memoria se devuelve automáticamente una vez que la variable que la posee queda fuera del alcance. Volvamos a los negocios. En Rust, para tipos complejos, operaciones como asignar un valor a una variable, pasarlo a una función o devolverlo desde una función no copian el valor: lo mueven. En pocas palabras, los tipos complejos mueven la propiedad. Cuando los tipos complejos ya no están dentro del alcance, Rust llamará a la función de eliminación para desasignar explícitamente la memoria del montón. Regla de propiedad 3 Cuando el propietario queda fuera del alcance, el valor se eliminará. Consideremos de nuevo el caso anterior: let s1 = String::from("hello"); let s2 = s1; println!("{}, world!", s1); // Won't compile. The value of s1 has already been dropped. El valor de ha disminuido después de que se asigna a (en la instrucción de asignación ). Por lo tanto, ya no es válido después de esta asignación. Aquí está la representación de la memoria después de que se haya descartado s1: s1 s1 s2 let s2 = s1 s1 Cómo se mueve la propiedad Hay tres formas de transferir la propiedad de una variable a otra en un programa de Rust: Asignar el valor de una variable a otra variable (ya se discutió). Pasar valor a una función. Volviendo de una función. Pasar valor a una función Pasar un valor a una función tiene una semántica similar a asignar un valor a una variable. Al igual que la asignación, pasar una variable a una función hace que se mueva o se copie. Eche un vistazo a este ejemplo, que muestra los casos de uso de copiar y mover: fn main() { let s = String::from("hello"); // s comes into scope move_ownership(s); // s's value moves into the function... // so it's no longer valid from this // point forward let x = 5; // x comes into scope makes_copy(x); // x would move into the function // It follows copy semantics since it's // primitive, so we use x afterward } // Here, x goes out of scope, then s. But because s's value was moved, nothing // special happens. fn move_ownership(some_string: String) { // some_string comes into scope println!("{}", some_string); } // Here, some_string goes out of scope and `drop` is called. // The occupied memory is freed. fn makes_copy(some_integer: i32) { // some_integer comes into scope println!("{}", some_integer); } // Here, some_integer goes out of scope. Nothing special happens. Si intentáramos usar s después de la llamada a , Rust arrojaría un error de tiempo de compilación. move_ownership Volviendo de una función Los valores devueltos también pueden transferir la propiedad. El siguiente ejemplo muestra una función que devuelve un valor, con anotaciones idénticas a las del ejemplo anterior. fn main() { let s1 = gives_ownership(); // gives_ownership moves its return // value into s1 let s2 = String::from("hello"); // s2 comes into scope let s3 = takes_and_gives_back(s2); // s2 is moved into // takes_and_gives_back, which also // moves its return value into s3 } // Here, s3 goes out of scope and is dropped. s2 was moved, so nothing // happens. s1 goes out of scope and is dropped. fn gives_ownership() -> String { // gives_ownership will move its // return value into the function // that calls it let some_string = String::from("yours"); // some_string comes into scope some_string // some_string is returned and // moves out to the calling // function } // This function takes a String and returns it fn takes_and_gives_back(a_string: String) -> String { // a_string comes into // scope a_string // a_string is returned and moves out to the calling function } La propiedad de una variable siempre sigue el mismo patrón: . A menos que la propiedad de los datos se haya trasladado a otra variable, cuando una variable que incluye datos en el montón queda fuera del alcance, el valor se eliminará mediante . un valor se mueve cuando se asigna a otra variable drop Con suerte, esto nos brinda una comprensión básica de qué es un modelo de y cómo influye en la forma en que Rust maneja los valores, como asignarlos entre sí y pasarlos dentro y fuera de las funciones. propiedad Esperar. Una cosa más… El modelo de propiedad de Rust, como todas las cosas buenas, tiene ciertos inconvenientes. Rápidamente nos damos cuenta de ciertos inconvenientes una vez que comenzamos a trabajar en Rust. Es posible que hayamos observado que tomar posesión y luego devolver la propiedad con cada función es un poco inconveniente. Es molesto que todo lo que pasamos a una función deba ser devuelto si queremos volver a utilizarla, además de cualquier otro dato devuelto por esa función. ¿Qué pasa si queremos que una función use un valor sin tomar posesión de él? Considere el siguiente ejemplo. El siguiente código generará un error porque la variable ya no puede ser utilizada por la función (¡en ) que la poseía inicialmente una vez que la propiedad se transfiere a la función . v main println! print_vector fn main() { let v = vec![10,20,30]; print_vector(v); println!("{}", v[0]); // this line gives us an error } fn print_vector(x: Vec ) { println!("Inside print_vector function {:?}",x); } El seguimiento de la propiedad puede parecer bastante fácil, pero puede complicarse cuando empezamos a tratar con programas grandes y complejos. Así que necesitamos una forma de transferir valores sin transferir la propiedad, que es donde entra en juego el concepto de . préstamo Préstamo Tomar prestado, en su sentido literal, se refiere a recibir algo con la promesa de devolverlo. En el contexto de Rust, es una forma de acceder al valor sin reclamar su propiedad, ya que debe devolverse a su propietario en algún momento. pedir prestado Cuando tomamos prestado un valor, hacemos referencia a su dirección de memoria con el operador . A se llama una . Las referencias en sí mismas no son nada especial; bajo el capó, son solo direcciones. Para aquellos familiarizados con los punteros C, una referencia es un a la memoria que contiene un valor que pertenece a (también conocido como de) otra variable. Vale la pena señalar que una referencia no puede ser nula en Rust. De hecho, una ; es el tipo más básico de puntero. Solo hay un tipo de puntero en la mayoría de los idiomas, pero Rust tiene diferentes tipos de punteros, en lugar de uno solo. Los punteros y sus diversos tipos son un tema diferente que se discutirá por separado. & & referencia puntero propiedad referencia es un puntero En pocas palabras, Rust se refiere a la creación de una referencia a algún valor como un préstamo del valor, que eventualmente debe devolverse a su propietario. Veamos un ejemplo simple a continuación: let x = 5; let y = &x; println!("Value y={}", y); println!("Address of y={:p}", y); println!("Deref of y={}", *y); Lo anterior produce el siguiente resultado: Value y=5 Address of y=0x7fff6c0f131c Deref of y=5 Aquí, la variable el número que a la variable , mientras que aún posee el valor. Llamamos una referencia a . El préstamo finaliza cuando sale del alcance y, como no posee el valor, no se destruye. Para tomar prestado un valor, tome una referencia del operador . El formato p, salida como una ubicación de memoria presentada como hexadecimal. y toma prestado pertenece x x y x y y & {:p} En el código anterior, "*" (es decir, un asterisco) es un operador de desreferencia que opera en una variable de referencia. Este operador de desreferenciación nos permite obtener el valor almacenado en la dirección de memoria de un puntero. Veamos cómo una función puede usar un valor sin tomar posesión a través de préstamos: fn main() { let v = vec![10,20,30]; print_vector(&v); println!("{}", v[0]); // can access v here as references can't move the value } fn print_vector(x: &Vec ) { println!("Inside print_vector function {:?}", x); } Estamos pasando una referencia ( ) (también conocida como ) a la función en lugar de transferir la propiedad (es decir, ). Como resultado, después de llamar a la función en la función principal, podemos acceder a . &v pass-by-reference print_vector pass-by-value print_vector v Seguimiento del puntero al valor con el operador de desreferencia Como se indicó anteriormente, una referencia es una especie de puntero, y un puntero puede considerarse como una flecha que apunta a un valor almacenado en otro lugar. Considere el siguiente ejemplo: let x = 5; let y = &x; assert_eq!(5, x); assert_eq!(5, *y); En el código anterior, creamos una referencia a un valor de tipo y luego usamos el operador de desreferencia para seguir la referencia a los datos. La variable tiene un valor de tipo , . Igualamos a una referencia a . i32 x i32 5 y x Así es como aparece la memoria de la pila: Podemos afirmar que es igual a . Sin embargo, si queremos hacer una afirmación sobre el valor en , debemos seguir la referencia al valor al que se refiere usando (por lo tanto, desreferencia aquí). Una vez que eliminamos la referencia a , tenemos acceso al valor entero al que apunta , que podemos comparar con . x 5 y *y y y 5 Si tratamos de escribir en su lugar, obtendríamos este error de compilación: assert_eq!(5, y); error[E0277]: can't compare `{integer}` with `&{integer}` --> src/main.rs:11:5 | 11 | assert_eq!(5, y); | ^^^^^^^^^^^^^^^^ no implementation for `{integer} == &{integer}` Debido a que son tipos diferentes, no se permite comparar un número y una referencia a un número. Por lo tanto, debemos usar el operador de desreferencia para seguir la referencia al valor al que apunta. Las referencias son inmutables por defecto Al igual que una variable, una referencia es inmutable de forma predeterminada; se puede convertir en mutable con , pero solo si su propietario también es mutable: mut let mut x = 5; let y = &mut x; Las referencias inmutables también se conocen como referencias compartidas, mientras que las referencias mutables también se conocen como referencias exclusivas. Considere el siguiente caso. Estamos otorgando acceso de solo lectura a las referencias ya que estamos usando el operador en lugar de . Incluso si la fuente es mutable, y no lo son, ya que son de solo lectura. & &mut n ref_to_n another_ref_to_n let mut n = 10; let ref_to_n = &n; let another_ref_to_n = &n; Borrow checker dará el siguiente error: error[E0596]: cannot borrow `x` as mutable, as it is not declared as mutable --> src/main.rs:4:9 | 3 | let x = 5; | - help: consider changing this to be mutable: `mut x` 4 | let y = &mut x; | ^^^^^^ cannot borrow as mutable Reglas de préstamo Uno podría preguntarse por qué un no siempre sería preferible a una . Si ese es el caso, ¿por qué Rust incluso tiene una semántica de y por qué no la toma de forma predeterminada? La razón es que no siempre es posible tomar prestado un valor en Rust. El endeudamiento sólo está permitido en determinados casos. préstamo mudanza movimiento prestada El préstamo tiene su propio conjunto de reglas, que el aplica estrictamente durante el tiempo de compilación. Estas reglas se establecieron para evitar . Son los siguientes: verificador de préstamo carreras de datos El alcance del prestatario no puede durar más que el alcance del propietario original. Puede haber varias referencias inmutables, pero solo una referencia mutable. Los propietarios pueden tener referencias inmutables o mutables, pero no ambas al mismo tiempo. Todas las referencias deben ser válidas (no pueden ser nulas). La referencia no debe sobrevivir al propietario. El alcance de una referencia debe estar contenido dentro del alcance del propietario del valor. De lo contrario, la referencia puede hacer referencia a un valor liberado, lo que genera un error liberación. de uso después de la let x; { let y = 0; x = &y; } println!("{}", x); El programa anterior intenta desreferenciar después de que el propietario quede fuera del alcance. Rust previene este error . x y de uso después de liberar Muchas referencias inmutables, pero solo se permite una referencia mutable Podemos tener tantas referencias inmutables (también conocidas como referencias compartidas) a un dato en particular a la vez, pero solo se permite una referencia mutable (también conocida como referencia exclusiva) a la vez. Esta regla existe para eliminar . Cuando dos referencias apuntan a la misma ubicación de memoria al mismo tiempo, al menos una de ellas está escribiendo y sus acciones están sincronizadas, esto se conoce como carrera de datos. carreras de datos no Podemos tener tantas referencias inmutables como queramos porque no cambian los datos. El préstamo, por otro lado, nos restringe a solo mantener una referencia mutable ( ) a la vez para evitar la posibilidad de carreras de datos en el momento de la compilación. &mut Veamos este: fn main() { let mut s = String::from("hello"); let r1 = &mut s; let r2 = &mut s; println!("{}, {}", r1, r2); } El código anterior que intenta crear dos referencias mutables ( y ) a fallará: r1 r2 s error[E0499]: cannot borrow `s` as mutable more than once at a time --> src/main.rs:6:14 | 5 | let r1 = &mut s; | ------ first mutable borrow occurs here 6 | let r2 = &mut s; | ^^^^^^ second mutable borrow occurs here 7 | 8 | println!("{}, {}", r1, r2); | -- first borrow later used here Palabras de cierre Con suerte, esto aclarará los conceptos de propiedad y préstamo. También mencioné brevemente el verificador de préstamos, la columna vertebral de la propiedad y los préstamos. Como mencioné al principio, la propiedad es una idea novedosa que puede ser difícil de comprender al principio, incluso para desarrolladores experimentados, pero se vuelve más y más fácil cuanto más trabajas en ella. Este es solo un resumen de cómo se aplica la seguridad de la memoria en Rust. Traté de hacer que esta publicación fuera lo más fácil de entender posible y al mismo tiempo proporcionar suficiente información para comprender los conceptos. Para obtener más detalles sobre la función de propiedad de Rust, consulte su en línea. documentación Rust es una excelente opción cuando el rendimiento es importante y resuelve los problemas que molestan a muchos otros idiomas, lo que da como resultado un importante paso adelante con una curva de aprendizaje empinada. Por sexto año consecutivo, , lo que implica que muchas personas que han tenido la oportunidad de usarlo se han enamorado de él. La comunidad de Rust sigue creciendo. Rust ha sido el lenguaje más querido de Stack Overflow : El año 2021 fue sin duda uno de los más trascendentales en la historia de Rust. Vio la fundación de Rust Foundation, la edición 2021 y una comunidad más grande que nunca. Rust parece estar en un buen camino a medida que nos dirigimos hacia el futuro. Según los resultados de Rust Survey 2021 ¡Feliz aprendizaje!